Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What and why?
What and why?
This PR builds on the work of #2058 and #2067, which introduced Fine-Grained Masking (FGM) overrides (see the RFC [internal] for more details). It implements the logic for applying touch privacy overrides at the view level, allowing views to have specific privacy settings that take precedence over global configurations.
How?
WindowTouchSnapshotProducer
.notify_sendEvent
), the applicable privacy setting is resolved, considering both view-level overrides and the global setting.overrideForTouch
dictionary is used to track privacy overrides for each ongoing touch event, ensuring the resolved privacy setting is reused throughout the lifecycle of the touch (from began to ended).🧪 Note: A flaky test in
SessionReplayOverrideTests
was also identified and fixed in this PR.👩🎨 Design Consideration: An alternative solution considered was to store the
Recorder.Context
within theWindowTouchSnapshotProducer
, injected during initialization, and updated from the recorder when necessary. This stored context would then be used in bothtakeSnapshot
andnotify_sendEvent
. However, this approach introduced complexity in managing the context state inside the snapshot producer, with potential issues around timing, synchronization, and the risk of stale contexts being used.Another alternative was to pass the entire recording context directly into
notify_sendEvent
, but this was not ideal since touch event processing only requires the global touch privacy, not the full recording context.The design decision was made to pass the global touch privacy during initialization because it is static and does not change during the session, meaning it only needs to be provided once. In contrast, the recording context can change and is therefore passed to
takeSnapshot
as needed, ensuring the correct context is used at the time of snapshot capture.📈 Performance Impact Note: Running the Shopist application [internal] on an iPhone 15, I measured the performance impact of
notify_sendEvent
of my feature branch (mariedm/FGM-overrides) compared to the current branch. The results are as follows:While this indicates a 40% slowdown, the absolute difference is just 20 μs, which is unlikely to be noticeable in most real-world scenarios. In most applications, an additional 20 μs per touch event is unlikely to affect performance in a meaningful way.
Review checklist
make api-surface
How?
A brief description of implementation details of this PR.
Review checklist
make api-surface